Posted on January 29, 2023
Welcome to my new blog!
Or rather, strictly speaking, welcome to my first blog!
Back when everybody had a blog, I had an old-fashioned personal website where pages were organized by topic rather than by date, so now that blogs are dead (or so they say), I guess it s time for me to have one :) .
The old website is still online, but updating it is getting harder, both for organizational reasons and because the static generator I ve used is no longer supported and requires python 2; lately I ve started publish some specific categories of material such as sewing patterns into their own website (you can find a list in the about page), but I was missing a place to post about the history and experiences of the things I publish elsewhere, as well as more uncategorized things.
Of course I ve chosen to use a static site generator, but since I m picky I ve discarded most of the common ones mostly because they enforce assumptions I don t agree with.
On the other hand, one day I wouldn t mind learning a bit of Haskell, so I decided to look for trouble and use Hakyll, hoping that nobody will add a level 20 wandering monster to it.
Right now I m using mostly the default theme, because I know that if I start fiddling with it I m not going to start posting content ever; maybe one day I ll decide to completely change the look.
As for contents, on the bits side of things you can expect me to talk about Debian, the Fediverse, Python, my inventory manging program and a bit of arduino-level electronics; on the atom side you should definitely expect sewing, modern and mostly historically inspired, some fiber crafts (spinning, knitting, crochet), maybe some bad attempts at painting (watercolours and acrilics), printing (screen and linocut), things that are written on paper and, well, any other craft I will happen to collect.
Before the blog gets too full I plan to add tag management to help people who are only interested in some of these contents.
This being a blog, of course it has an atom feed you can add to your favourite (and ideally self-hosted) rss reader, and since this is a personal blog there will be no periodicity, posts will happen when I ll have something to say on some topic.
Until next time
Dealing with the void during MiniDebConf Online #1
Between 28 and 31 May this year, we set out to create our first ever online MiniDebConf for Debian. Many people have been meaning to do something similar for a long time, but it just didn t work out yet. With many of us being in lock down due to COVID-19, and with the strong possibility looming that DebConf20 might have had to become an online event, we rushed towards organising the first ever Online MiniDebConf and put together some form of usable video stack for it.
I could go into all kinds of details on the above, but this post is about a bug that lead to a pretty nifty feature for DebConf20. The tool that we use to capture Jitsi calls is called Jibri (Jitsi Broadcasting Infrustructure). It had a bug (well, bug for us, but it s an upstream feature) where Jibri would hang up after 30s of complete silence, because it would assume that the call has ended and that the worker can be freed up again. This would result in the stream being ended at the end of every talk, so before the next talk, someone would have to remember to press play again in their media player or on the video player on the stream page. Hrmph.
Easy solution on the morning that the conference starts? I was testing a Debian Live image the night before in a KVM and thought that I might as well just start a Jitsi call from there and keep a steady stream of silence so that Jibri doesn t hang up.
It worked! But the black screen and silence on stream was a bit eery. Because this event was so experimental in nature, and because we were on such an incredibly tight timeline, we opted not to seek sponsors for this event, so there was no sponsors loop that we d usually stream during a DebConf event. Then I thought Ah! I could just show the schedule! .
The stream looked bright and colourful (and was even useful!) and Jitsi/Jibri didn t die. I thought my work was done. As usual, little did I know how untrue that was.
The silence was slightly disturbing after the talks, and people asked for some music. Playing music on my VM and capturing the desktop audio in to Jitsi was just a few pulseaudio settings away, so I spent two minutes finding some freely licensed tracks that sounded ok enough to just start playing on the stream. I came across mini-albums by Captive Portal and Cinema Noir, During the course of the MiniDebConf Online I even started enjoying those. Someone also pointed out that it would be really nice to have a UTC clock on the stream. I couldn t find a nice clock in a hurry so I just added a tmux clock in the meantime while we deal with the real-time torrent of issues that usually happens when organising events like this.
Speaking of issues, during our very first talk of the last day, our speaker had a power cut during the talk and abruptly dropped off. Oops! So, since I had a screenshare open from the VM to the stream, I thought I d just pop in a quick message in a text editor to let people know that we re aware of it and trying to figure out what s going on.
In the end, MiniDebConf Online worked out all right. Besides the power cut for our one speaker, and another who had a laptop that was way too under-powered to deal with video, everything worked out very well. Even the issues we had weren t show-stoppers and we managed to work around them.
DebConf20 Moves Online
For DebConf, we usually show a sponsors loop in between sessions. It s great that we give our sponsors visibility here, but in reality people see the sponsors loop and think Talk over! and then they look away. It s also completely silent and doesn t provide any additional useful information. I was wondering how I could take our lessons from MDCO#1 and integrate our new tricks with the sponsors loop. That is, add the schedule, time, some space to type announcements on the screen and also add some loopable music to it.
I used OBS before in making my videos, and like the flexibility it provides when working with scenes and sources. A scene is what you would think of as a screen or a document with its own collection of sources or elements. For example, a scene might contain sources such as a logo, clock, video, image, etc. A scene can also contain another scene. This is useful if you want to contain a banner or play some background music that is shared between scenes.
The above screenshots illustrate some basics of scenes and sources. First with just the DC20 banner, and then that used embedded in another scene.
For MDCO#1, I copied and pasted the schedule into a LibreOffice Impress slide that was displayed on the stream. Having to do this for all 7 days of DebConf, plus dealing with scheduling changes would be daunting. So, I started to look in to generating some schedule slides programmatically. Stefano then pointed me to the Happening Now page on the DebConf website, where the current schedule block is displayed. So all I would need to do in OBS was to display a web page. Nice!
Unfortunately the OBS in Debian doesn t have the ability to display web pages out of the box (we need to figure out CEF in Debian), but fortunately someone provides a pre-compiled version of the plugin called Linux Browser that works just fine. This allowed me to easily add the schedule page in its own scene.
Being able to display a web page solved another problem. I wasn t fond of having to type / manage the announcements in OBS. It would either be a bit prone to user error, and if you want to edit the text while the loop is running, you d have to disrupt the loop, go to the foreground scene, and edit the text before resuming the loop. That s a bit icky. Then I thought that we could probably just get that from a web page instead. We could host some nice html snippet in a repository in salsa, and then anyone could easily commit an MR to update the announcement.
But then I went a step further, use an etherpad! Then anyone in the orga team can quickly update the announcement and it would be instantly changed on the stream. Nice! So that small section of announcement text on the screen is actually a whole web browser with an added OBS filter to crop away all the pieces we don t want. Overkill? Sure, but it gave us a decent enough solution that worked in time for the start of DebConf. Also, being able to type directly on to the loop screen works out great especially in an emergency. Oh, and uhm the clock is also a website rendered in its own web browser :-P
So, I had the ability to make scenes, add elements and add all the minimal elements I wanted in there. Great! But now I had to figure out how to switch scenes automatically. It s probably worth mentioning that I only found some time to really dig into this right before DebConf started, so with all of this I was scrambling to find things that would work without too many bugs while also still being practical.
Now I needed the ability to switch between the scenes automatically / programmatically. I had never done this in OBS before. I know it has some API because there are Android apps that you can use to control OBS with from your phone. I discovered that it had an automatic scene switcher, but it s very basic. It can only switch based on active window, which can be useful in some cases, but since we won t have any windows open other than OBS, this tool was basically pointless.
After some quick searches, I found a plugin called Advanced Scene Switcher. This plugin can do a lot more, but has some weird UI choices, and is really meant for gamers and other types of professional streamers to help them automate their work flow and doesn t seem at all meant to be used for a continuous loop, but, it worked, and I could make it do something that will work for us during the DebConf.
I had a chicken and egg problem because I had to figure out a programming flow, but didn t really have any content to work with, or an idea of all the content that we would eventually have. I ve been toying with the idea in my mind and had some idea that we could add fun facts, postcards (an image with some text), time now in different timezones, Debian news (maybe procured by the press team), cards that contain the longer announcements that was sent to debconf-announce, perhaps a shout out or two and some photos from previous DebConfs like the group photos. I knew that I wouldn t be able to build anything substantial by the time DebConf starts, but adding content to OBS in between talks is relatively easy, so we could keep on building on it during DebConf.
Nattie provided the first shout out, and I made 2 video loops with the DC18/19 pictures and also two Did you know cards. So the flow I ended up with was: Sponsors -> Happening Now -> Random video (which would be any of those clips) -> Back to sponsors. This ended up working pretty well for quite a while. With the first batch of videos the sponsor loop would come up on average about every 2 minutes, but as much shorter clips like shout outs started to come in faster and faster, it made sense to play a few 2-3 shout-outs before going back to sponsors.
So here is a very brief guide on how I set up the sequencing in Advanced Scene Switcher.
If no condition was met, a video would play from the Random tab.
Then in the Random tab, I added the scenes that were part of the random mix. Annoyingly, you have to specify how long it should play for. If you don t, the no condition thingy is triggered and another video is selected. The time is also the length of the video minus one second, because
You can t just say that a random video should return back to a certain scene, you have to specify that in the sequence tab for each video. Why after 1 second? Because, at least in my early tests, and I didn t circle back to this, it seems like 0s can randomly either mean instantly, or never. Yes, this ended up being a bit confusing and tedious, and considering the late hours I worked on this, I m surprised that I didn t manage to screw it up completely at any point.
I also suspected that threads would eventually happen. That is, when people create video replies to other videos. We had 3 threads in total. There was a backups thread, beverage thread and an impersonation thread. The arrow in the screenshot above points to the backups thread. I know it doesn t look that complicated, but it was initially somewhat confusing to set up and make sense out of it.
For the next event, the Advanced Scene Switcher might just get some more taming, or even be replaced entirely. There are ways to drive OBS by API, and even the Advanced Scene Switcher tool can be driven externally to some degree, but I think we definitely want to replace it by the next full DebConf. We had the problem that when a talk ended, we would return to the loop in the middle of a clip, which felt very unnatural and sometimes even confusing. So Stefano helped me with a helper script that could read the socket from Vocto, which I used to write either Loop or Standby to a file, and then the scene switcher would watch that file and keep the sponsors loop ready for start while the talks play. Why not just switch to sponsors when the talk ends? Well, the little bit of delay in switching would mean that you would see a tiny bit of loop every time before switching to sponsors. This is also why we didn t have any loop for the ad-hoc track (that would have probably needed another OBS instance, we ll look more into solutions for this for the future).
Then for all the clips. There were over 50 of them. All of them edited by hand in kdenlive. I removed any hard clicks, tried to improve audibility, remove some sections at the beginning and the end that seemed extra and added some music that would reduce in volume when someone speaks. In the beginning, I had lots of fun with choosing music for the clips. Towards the end, I had to rush them through and just chose the same tune whether it made sense or not. For comparison of what a difference the music can make, compare the original and adapted version for Valhalla s clip above, or this original and adapted video from urbec. This part was a lot more fun than dealing with the video sequencer, but I also want to automate it a bit. When I can fully drive OBS from Python I ll likely instead want to show those cards and control music volume from Python (what could possibly go wrong ).
The loopy name happened when I requested an @debconf.org alias for this. I was initially just thinking about loop@debconf.org but since I wanted to make it clear that the purpose of this loop is also to have some fun, I opted for loopy instead:
I was really surprised by how people took to loopy. I hoped it would be good and that it would have somewhat positive feedback, but the positive feedback was just immense. The idea was that people typically saw it in between talks. But a few people told me they kept it playing after the last talk of the day to watch it in the background. Some asked for the music because they want to keep listening to it while working (and even for jogging!?). Some people also asked for recordings of the loop because they want to keep it for after DebConf. The shoutouts idea proved to be very popular. Overall, I m very glad that people enjoyed it and I think it s safe to say that loopy will be back for the next event.
Also throughout this experiment Loopy Loop turned into yet another DebConf mascot. We gain one about every DebConf, some by accident and some on purpose. This one was not quite on purpose. I meant to make an image for it for salsa, and started with an infinite loop symbol. That s a loop, but by just adding two more solid circles to it, it looks like googly eyes, now it s a proper loopy loop!
I like the progress we ve made on this, but there s still a long way to go, and the ideas keep heaping up. The next event is quite soon (MDCO#2 at the end of November, and it seems that 3 other MiniDebConf events may also be planned), but over the next few events there will likely be significantly better graphics/artwork, better sequencing, better flow and more layout options. I hope to gain some additional members in the team to deal with incoming requests during DebConf. It was quite hectic this time! The new OBS also has a scripting host that supports Python, so I should be able to do some nice things even within OBS without having to drive it externally (like, display a clock without starting a web browser).
The Loopy Loop Music
The two mini albums that mostly played during the first few days were just a copy and paste from the MDCO#1 music, which was:
I have much more things to say about DebConf20, but I ll keep that for another post, and hopefully we can get all the other video stuff in a post from the video team, because I think there s been some real good work done for this DebConf. Also thanks to Infomaniak who was not only a platinum sponsor for this DebConf, but they also provided us with plenty of computing power to run all the video stuff on. Thanks again!
On 2017-08-06 I have a talk at DebConf17 in
Montreal titled
"Consensually doing things together?"
(video).
Here are the talk notes.
Abstract
At DebConf Heidelberg I talked about how Free Software has a lot to do about
consensually doing things together. Is that always true, at least in Debian?
I d like to explore what motivates one to start a project and what motivates
one to keep maintaining it. What are the energy levels required to manage bits
of Debian as the project keeps growing. How easy it is to say no. Whether we
have roles in Debian that require irreplaceable heroes to keep them going. What
could be done to make life easier for heroes, easy enough that mere mortals can
help, or take their place.
Unhappy is the community that needs heroes, and unhappy is the community that
needs martyrs.
I d like to try and make sure that now, or in the very near future, Debian is
not such an unhappy community.
Consensually doing things together
I gave a talk in Heidelberg.
Valhallamadestickers
Debian France distributed
many of them.
There's one on my laptop.
Which reminds me of what we ought to be doing.
Of what we have a chance to do, if we play our cards right.
I'm going to talk about relationships. Consensual relationships.
Relationships in short.
Nonconsensual relationships are usually called abuse.
I like to see Debian as a relationship between multiple people.
And I'd like it to be a consensual one.
I'd like it not to be abuse.
Consent
From wikpedia:
In Canada "consent means the voluntary agreement of the complainant to engage
in sexual activity" without abuse or exploitation of "trust, power or
authority", coercion or threats.[7] Consent can also be revoked at any
moment.[8]
There are 3 pillars often included in the description of sexual consent, or
"the way we let others know what we're up for, be it a good-night kiss or the
moments leading up to sex."
They are:
Knowing exactly what and how much I'm agreeing to
Expressing my intent to participate
Deciding freely and voluntarily to participate[20]
Saying "I've decided I won't do laundry anymore" when the other partner is
tired, or busy doing things.
Is different than saying "I've decided I won't do laundry anymore" when the
other partner has a chance to say "why? tell me more" and take part in
negotiation.
Resources:
Relationships
Debian is the Universal Operating System.
Debian is made and maintained by people.
The long term health of debian is a consequence of the long term health of the
relationship between Debian contributors.
Debian doesn't need to be technically perfect, it needs to be socially healthy.
Technical problems can be fixed by a healty community.
The Thomas-Kilmann Conflict Mode Instrument: sourcepng.
Motivations
Quick poll:
how many of you do things in Debian because you want to?
how many of you do things in Debian because you have to?
how many of you do both?
What are your motivations to be in a relationship?
Which of those motivations are healthy/unhealthy?
healthy sustain the relationship
unhealthy may explode spectacularly at some point
"Galadriel" (noun, by Francesca Ciceri): a task you have to do otherwise Sauron takes over Middle Earth
See: http://blog.zouish.org/nonupdd/#/22/1
What motivates me to start a project or pick one up?
I have an idea for for something fun or useful
I see something broken and I have an idea how to fix it
What motivates me to keep maintaning a project?
Nobody else can do it
Nobody else can be trusted to do it
Nobody else who can and can be trusted to do it is doing it
Somebody is paying me to do it
What motivates you?
What's an example of a sustainable motivation?
it takes me little time?
it's useful for me
It's fun
It saves me time to keep something running that if it breaks when I or somebody else needs it
it makes me feel useful? (then if I stop, I become useless, then I can't afford to stop?)
Getting positive feedback (more "you're good" than "i use it") ?
Is it really all consensual in Debian?
what tasks are done by people motivated by guilt / motivated by Galadriel?
if I volunteer to help team X that is in trouble, will I get stuck doing
all the work as soon as people realise things move fine again and finally
feel free to step back?
Energy
Energy that thing which is measured in spoons. The metaphore comes from people suffering with chronic health issues:
"Spoons" are a visual representation used as a unit of measure used to
quantify how much energy a person has throughout a given day. Each activity
requires a given number of spoons, which will only be replaced as the person
"recharges" through rest. A person who runs out of spoons has no choice but
to rest until their spoons are replenished.
are the things that we expect a person to do the things that one person can
do?
having a history of people who can do it anyway is no excuse: show
compassion to those people, take some of their work, thank them, but don't
glorify them
Have reasonable expectations, on others:
If someone is out of spoons, they're out of spoons; they don't get more
spoons if you insist; if you insist, you probably take even more spoons from
them
If someone needs their spoons for something else, they are entitled to
If someone gets out of spoons for something important, and nobody else can
do it, it's not their fault but a shared responsibility
Have reasonable expectations, on yourself:
If you are out of spoons, you are out of spoons
If you need spoons for something else, use them for something else
If you are out of spoons for something important, and nobody else can do it,
it's not your problem, it's a problem in the community
Debian is a shared responsibility
Don't expect few people to take care of everything
Leave space for more people to take responsibility for things
Turnover empowers
Humans are a renewable resource, but only if you think of them that way
When spoons are limited, what takes more energy tends not to get done
routine is ok
non-routine tends to get stuck in the mailbox waiting for a day with more
free time
are we able to listen when tricky cases happen?
are we able to respond when tricky cases happen?
are we able to listen/respond when socially tricky cases happen?
are we able to listen/respond when harassment happens?
can we tell people raising valid issues from troublemakers?
in NM
it's easier to accept a new maintainer than to reject them
it's hard or impossible to make a call on a controversial candidate when
one doesn't know that side of Debian
I'm tired, why you report a bug? I don't want to deal with your bug.
Maybe you are wrong and your bug is invalid? It would be good if you were
wrong and your bug was invalid.
even politeness goes when out of spoons because it's too much effort
As the project grows, project-wide tasks become harder
Are they still humanly achievable?
release team
DAM (amount of energy to deal with when things go wrong; only dealing with
when things go spectacularly wrong?)
DPL (how many people candidate to this year elections?)
I don't want Debian to have positions that require hero-types to fill them
heroes are rare
heroes are hard to replace
heroes burn out
heroes can become martyrs
heroes can become villains
heroes tend to be accidents waiting to happen
Dictatorship of who has more spoons:
Someone who has a lot of energy can take more and more tasks out of people
who have less, and slowly drive all the others away
Good for results, bad for the team
Then we have another person who is too big to fail, and another accident
waiting to happen
Perfectionism
You are in a relationship that is just perfect. All your friends look up to
you. You give people relationship advice. You are safe in knowing that You Are
Doing It Right.Then one day you have an argument in public.You don't just have to deal with the argument, but also with your reputation
and self-perception shattering.
One things I hate about Debian: consistent technical excellence.
I don't want to be required to always be right.
One of my favourite moments in the history of Debian is
the openssl bug
Debian doesn't need to be technically perfect, it needs to be socially healthy,
technical problems can be fixed.
I want to remove perfectionism from Debian: if we discover we've been wrong all
the time in something important, it's not the end of Debian, it's the beginning
of an improved Debian.
Too good to be true
There comes a point in most people's dating experience where one learns that
when some things feel too good to be true, they might indeed be.
There are people who cannot say no:
you think everything is fine, and you discover they've been suffering all
the time and you never had a clue
There are people who cannot take a no:
They depend on a constant supply of achievement or admiration to have a
sense of worth, therefore have a lot of spoons to invest into getting it
However, when something they do is challenged, such as by pointing out a
mistake one has made, or a problem with their behaviour, all hell breaks
loose, beacuse they see their whole sense of worth challenged, too
Note the diversity statement: it's not a problem to have one of those (and many
other) tendencies, as long as one manages to keep interacting constructively
with the rest of the community
Also, it is important to be aware of these patterns, to be able to compensate
for one's own tendencies. What happens when an avoidant person meets a
narcissistic person, and they are both unaware of the risks?
Resources:
Note: there are problems with the way these resources are framed:
These topics are often very medicalised, and targeted at people who are
victims of abuse and domestic violence.
I find them useful to develop regular expressions for pattern matching of
behaviours, and I consider them dangerous if they are used for pattern
matching of people.
you had an argument with someone and the outcome was positive for both
Red flags:
you feel demeaned
you feel invalidated
Apologies / Dealing with issues
I don't see the usefulness of apologies that are about accepting blame, or
making a person stop complaining.
I see apologies as opportunities to understand the problem I caused, help fix
it, and possibly find ways of avoiding causing that problem again in the
future.
A Better Way to Say Sorry
lists a 4 step process, which is basically what we do when in bug reports
already:
1, Try to understand and reproduce the exact problem the person had.
2. Try to find the cause of the issue.
3. Try to find a solution for the issue.
4. Verify with the reporter that the solution does indeed fix the issue.
This is just to say
My software ate
the files
that where in
your home directory
and which
you were probably
needing
for work
Forgive me
it was so quick to write
without tests
and it worked so well for me
(inspired by a 1934 poem by William Carlos Williams)
Don't be afraid to fail
Don't be afraid to fail or drop the ball.
I think that anything that has a label attached of "if you don't do it, nobody
will", shouldn't fall on anybody's shoulders and should be shared no matter
what.
Shared or dropped.
Share the responsibility for a healthy relationship
Don't expect that the more experienced mates will take care of everything.
In a project with active people counted by the thousand, it's unlikely that
harassment isn't happening. Is anyone writing anti-harassment? Do we have
stats? Is having an email address and a CoC giving us a false sense of
security?
When you get involved in a new community, such as Debian, find out early
where, if that happens, you can find support, understanding, and help to make
it stop.
If you cannot find any, or if the only thing you can find is people who say
"it never happens here", consider whether you really want to be in that
community.
There are some nice people in the world. I mean nice people, the sort I couldn t describe myself as. People who are friends with everyone, who are somehow never involved in any argument, who seem content to spend their time drawing pictures of bumblebees on flowers that make everyone happy.
Those people are great to have around. You want to hold onto them as much as you can.
But people only have so much tolerance for jerkiness, and really nice people often have less tolerance than the rest of us.
The trouble with not ejecting a jerk whether their shenanigans are deliberate or incidental is that you allow the average jerkiness of the community to rise slightly. The higher it goes, the more likely it is that those really nice people will come around less often, or stop coming around at all. That, in turn, makes the average jerkiness rise even more, which teaches the original jerk that their behavior is acceptable and makes your community more appealing to other jerks. Meanwhile, more people at the nice end of the scale are drifting away.
(from https://eev.ee/blog/2016/07/22/on-a-technicality/)
Give people freedom
If someone tries something in Debian, try to acknowledge and accept their work.
You can give feedback on what they are doing, and try not to stand in their
way, unless what they are doing is actually hurting you. In that case, try to
collaborate, so that you all can get what you need.
It's ok if you don't like everything that they are doing.
I personally don't care if people tell me I'm good when I do something, I
perceive it a bit like "good boy" or "good dog". I rather prefer if people show
an interest, say "that looks useful" or "how does it work?" or "what do you
need to deploy this?"
Acknowledge that I've done something. I don't care if it's especially liked,
give me the freedom to keep doing it.
Don't give me rewards, give me space and dignity.
Rather than feeding my ego, feed by freedom, and feed my possibility to create.
I'm stuck home instead of being able to go to DebConf, but that doesn't mean that Debian Day will be left uncelebrated!
Since many of the locals are away for the holidays, we of @Gruppo Linux Como and @LIFO aren't going to organize a full day of celebrations, but at the very least we are meeting for a dinner in Varese, at some restaurant that will be open on that date.
Everybody is welcome: to join us please add your name (nickname or identifier of any kind, as long as it fits in the box) on https://dudle.inf.tu-dresden.de/debdayvarese2017/ before thursday, August 10th, so that we can get a reservation at the restaurant.
I understand that somebody on the internet will always be trolling, but I just wanted to point out:
* that the installer in the old live images has been broken (for international users) for years * that nobody cared enough to fix it, not even the people affected by it (the issue was reported as known in various forums, but for a long time nobody even opened an issue to let the *developers* know).
Compare this with the current situation, with people doing multiple tests as the (quite big number of) images were being built, and a fix released soon after for the issues found.
I'd say that this situation is great, and that instead of trolling around we should thank the people involved in this release for their great job.
I've been thinking for a while that an half-size set could be useful, and between yesterday and today I've actually managed to do the first version.
It's (2d) printed on both sides of a single sheet of heavy paper, laminated and then cut, comes with both the basic suites and the playing card expansion and fits in a mint tin divided by origami boxes.
It's just version 0.1 because there are a few issues: first of all I'm not happy with the manual way I used to draw the page: ideally it would have been programmatically generated from the same svg files as the 3d piecepack (with the ability to generate other expansions), but apparently reading paths from an svg and writing it in another svg is not supported in an easy way by the libraries I could find, and looking for it was starting to take much more time than just doing it by hand.
I also still have to assemble the dice; in the picture above I'm just using the ones from the 3d-printed set, but they are a bit too big and only four of them fit in the mint tin. I already have the faces printed, so this is going to be fixed in the next few days.
Source files are available in the same git repository as the 3d-printable piecepack http://git.trueelena.org/cgit.cgi/3d/piecepack/, with the big limitation mentioned above; updates will also be pushed there, just don't hold your breath for it :)
I now have an XMPP setup which has all the features of the recent fancy chat systems, and on top of that it runs, client and server, on Free Software, which can be audited, it is federated and I can self-host my own server in my own VPS if I want to, with packages supported in Debian.
I'm also targeting https://www.debian.org/ stable (+ backports); as I write this is jessie; if there are significant differences I will update this article when I will upgrade my server to stretch. Right now, this means that I'm using prosody 0.9 (and that's probably also the version that will be available in stretch).
Installation and prerequisites
You will need to enable the https://backports.debian.org/ repository and then install the packages prosody and prosody-modules.
the "local" configures prosody so that only local users are allowed to create new rooms (but then everybody can join them, if the room administrator allows it): this may help reduce unwanted usages of your server by random people.
You can also add the following line to enable rich media transfers via http uploads (XEP-0363):
Don't forget to enable the virtualhost by linking the file inside /etc/prosody/conf.d/.
additional modules
Most of the other interesting XEPs are enabled by loading additional modules inside /etc/prosody/prosody.cfg.lua (under modules_enabled); to enable mod_something just add a line like:
"something";
Most of these come from the prosody-modules package (and thus from https://modules.prosody.im/ ) and some may require changing when prosody 0.10 will be available; when this is the case it is mentioned below.
mod_carbons (XEP-0280) To keep conversations syncronized while using multiple devices at the same time.
This will be included by default in prosody 0.10.
mod_privacy + mod_blocking (XEP-0191) To allow user-controlled blocking of users, including as an anti-spim measure.
In prosody 0.10 these two modules will be replaced by mod_privacy.
mod_smacks (XEP-0198) Allow clients to resume a disconnected session before a customizable timeout and prevent message loss.
mod_mam (XEP-0313) Archive messages on the server for a limited period of time (default 1 week) and allow clients to retrieve them; this is required to syncronize message history between multiple clients.
With prosody 0.9 only an in-memory storage backend is available, which may make this module problematic on servers with many users. prosody 0.10 will fix this by adding support for an SQL backed storage with archiving capabilities.
mod_throttle_presence + mod_filter_chatstates (XEP-0352) Filter out presence updates and chat states when the client announces (via Client State Indication) that the user isn't looking. This is useful to reduce power and bandwidth usage for "useless" traffic.
It was plagued with issues; one of the sleeve is wrong side out and I only realized it when everything was almost done (luckily the pattern is symmetric and it is barely noticeable) and the swirl moved while I was sewing it on (and the sewing machine got stuck multiple times: next time I'm using interfacing, full stop.), and it's a bit deformed, but it's done.
For the swirl, I used Inkscape to Simplify (Ctrl-L) the original Debian Swirl a few times, removed the isolated bits, adjusted some spline nodes by hand and printed on paper. I've then cut, used water soluble glue to attach it to the wrong side of a scrap of red fabric, cut the fabric, removed the paper and then pinned and sewed the fabric on the pajama top. As mentioned above, the next time I'm doing something like this, some interfacing will be involved somewhere, to keep me sane and the sewing machine happy.
XMPP VirtualHosts, SRV records and letsencrypt certificates
When I set up my XMPP server, a friend of mine asked if I was willing to have a virtualhost with his domain on my server, using the same address as the email.
Setting up prosody and the SRV record on the DNS was quite easy, but then we stumbled on the issue of certificates: of course we would like to use letsencrypt, but as far as we know that means that we would have to setup something custom so that the certificate gets renewed on his server and then sent to mine, and that looks more of a hassle than just him setting up his own prosody/ejabberd on his server.
So I was wondering: dear lazyweb, did any of you have the same issue and already came up with a solution that is easy to implement and trivial to maintain that we missed?
This was rectified by the article by David Boddie http://www.boddie.org.uk/david/www-repo/Personal/Updates/2017/2017-02-11.html which makes an apt comparison of Android to the platform it is replacing in many areas of work and life: Microsoft Windows and criticises its lack of effective freedom, even when the OS was supposed to be under a free license.
I fully agree that lightweight/low powered hardware can be an excellent work environment, especially when on the go, and even for many kinds of software developement, but I'd very much rather have that hardware run an environment that I can trust like Debian (or another traditional GNU/Linux distribution) rather than the phone based ones where, among other problems, there is no clear distinction between what is local and trustable and what is remote and under somebody else's control.
In theory, it would be perfectly possible to run Debian on most tablet and tablet-like hardware, and have such an environment; in practice this is hard for a number of reasons including the lack of mainline kernel support for most hardware and the way actually booting a different OS on it usually ranges from the quite hard to the downright impossible.
Luckily, there is some niche hardware that uses tablet/phone SoCs but is sold with a GNU/Linux distribution and can be used as a freedom respecting work environment on-the-go: my current setup includes an OpenPandora https://en.wikipedia.org/wiki/Pandora_(console) (running Angstrom + a Debian chroot) and an Efika MX Smartbook https://en.wikipedia.org/wiki/Efika, but they are both showing their age badly: they have little RAM (especially the Pandora), and they aren't fully supported by a mainline kernel, which means that you're stuck on an old kernel and dependent on the producer for updates (which for the Efika ended quite early; at least the Pandora is still somewhat supported, at least for bugfixes).
As for software, the laptop/clamshell designs means that using a regular Desktop Environment (or, in my case, Window Manager) works just fine; I do hope that the availability of Pyra (with its touchscreen and 4G/"phone" chip) will help to give a bit of life back to the efforts to improve mobile software on Debian https://wiki.debian.org/Mobile
Hopefully, more such devices will continue to be available, and also hopefully the trend for more openness of the hardware itself will continue; sadly I don't see this getting outside of a niche market in the next few years, but I think that this niche will remain strong enough to be sustainable.
P.S. from nitpicker-me: David Boddie mentions the ability to easily download sources for any component with apt-get source: the big difference IMHO is given by apt-get build-dep, which also install every dependency needed to actually build the code you have just downloaded.
P.S.2: I also agree with Davide Boddie that supporting Conservancy https://sfconservancy.org/supporter/ is very important, and there are still a few hours left to have the contribution count twice.
After many days of failed attempts, yesterday @Diego Roversi finally managed to setup SPI on the BeagleBone White , and that means that today at our home it was Laptop Liberation Day!
We took the spare X200, opened it, found the point we were on in the tutorial installing libreboot on x200 https://libreboot.org/docs/install/x200_external.html, connected all of the proper cables on the clip and did some reading tests of the original bios.
While the tutorial mentioned a very conservative setting (512kHz), just for fun we tried to read it at different speed and all results up to 16384 kHz were equal, with the first failure at 32784 kHz, so we settled on using 8192 kHz.
Then it was time to customize our libreboot image with the right MAC address, and that's when we realized that the sheet of paper where we had written it down the last time had been put in a safe place somewhere
Luckily we also had taken a picture, and that was easier to find, so we checked the keyboard map , followed the instructions to customize the image https://libreboot.org/docs/hcl/gm45_remove_me.html#ich9gen, flashed the chip, partially reassembled the laptop, started it up and a black screen, some fan noise and nothing else.
We tried to reflash the chip (nothing was changed), tried the us keyboard image, in case it was the better tested one (same results) and reflashed the original bios, just to check that the laptop was still working (it was).
It was lunchtime, so we stopped our attempts. As soon as we started eating, however, we realized that this laptop came with 3GB of RAM, and that surely meant "no matching pairs of RAM", so just after lunch we reflashed the first image, removed one dimm, rebooted and finally saw a gnu-hugging penguin!
We then tried booting some random live usb key https://tails.boum.org/ we had around (failed the first time, worked the second and further one with no changes), and then proceeded to install Debian.
Running the installer required some attempts and a bit of duckduckgoing: parsing the isolinux / grub configurations from the libreboot menu didn't work, but in the end it was as easy as going to the command line and running:
linux (usb0)/install.amd/vmlinuz initrd (usb0)/install.amd/initrd.gz boot
From there on, it was the usual debian installation and a well know environment, and there were no surprises. I've noticed that grub-coreboot is not installed (grub-pc is) and I want to investigate a bit, but rebooting worked out of the box with no issue.
Next step will be liberating my own X200 laptop, and then if you are around the @Gruppo Linux Como area and need a 16 pin clip let us know and we may bring everything to one of the LUG meetings
yes, white, and most of the instructions on the interwebz talk about the black, which is extremely similar to the white except where it isn't
wait? there are keyboard maps? doesn't everybody just use the us one regardless of what is printed on the keys? Do I *live* with somebody who doesn't? :D
the breadboard in the picture is only there for the power supply, the chip on it is a cheap SPI flash used to test SPI on the bone without risking the laptop :)
disclaimer: it worked for us. it may not work on *your* laptop. it may brick it. it may invoke a tentacled monster, it may bind your firstborn son to a life of servitude to some supernatural being. Whatever happens, it's not our fault.
I now have an XMPP setup which has all the features of the recent fancy chat systems, and on top of that it runs, client and server, on Free Software, which can be audited, it is federated and I can self-host my own server in my own VPS if I want to, with packages supported in Debian.
I'm also targeting https://www.debian.org/ stable (+ backports); as I write this is jessie; if there are significant differences I will update this article when I will upgrade my server to stretch. Right now, this means that I'm using prosody 0.9 (and that's probably also the version that will be available in stretch).
Installation and prerequisites
You will need to enable the https://backports.debian.org/ repository and then install the packages prosody and prosody-modules.
the "local" configures prosody so that only local users are allowed to create new rooms (but then everybody can join them, if the room administrator allows it): this may help reduce unwanted usages of your server by random people.
You can also add the following line to enable rich media transfers via http uploads (XEP-0363):
Don't forget to enable the virtualhost by linking the file inside /etc/prosody/conf.d/.
additional modules
Most of the other interesting XEPs are enabled by loading additional modules inside /etc/prosody/prosody.cfg.lua (under modules_enabled); to enable mod_something just add a line like:
"something";
Most of these come from the prosody-modules package (and thus from https://modules.prosody.im/ ) and some may require changing when prosody 0.10 will be available; when this is the case it is mentioned below.
mod_carbons (XEP-0280) To keep conversations syncronized while using multiple devices at the same time.
This will be included by default in prosody 0.10.
mod_privacy + mod_blocking (XEP-0191) To allow user-controlled blocking of users, including as an anti-spim measure.
In prosody 0.10 these two modules will be replaced by mod_privacy.
mod_smacks (XEP-0198) Allow clients to resume a disconnected session before a customizable timeout and prevent message loss.
mod_mam (XEP-0313) Archive messages on the server for a limited period of time (default 1 week) and allow clients to retrieve them; this is required to syncronize message history between multiple clients.
With prosody 0.9 only an in-memory storage backend is available, which may make this module problematic on servers with many users. prosody 0.10 will fix this by adding support for an SQL backed storage with archiving capabilities.
mod_throttle_presence + mod_filter_chatstates (XEP-0352) Filter out presence updates and chat states when the client announces (via Client State Indication) that the user isn't looking. This is useful to reduce power and bandwidth usage for "useless" traffic.
Conversations is a really nice, actively
developed, up to date XMPP client for Android that has the nice feature of
telling you what XEPs
are supported by the server one is using:
Some days ago, me and Valhalla
played the game of trying to see what happens when one turns them all on: I
would send her screenshots from my Conversations, and she would poke at her
Prosody to try and turn things on:
Valhalla eventually managed to get all features activated, purely using
packages from Jessie+Backports:
The result was a chat system in which I could see the same conversation history
on my phone and on my laptop (with gajim)(https://gajim.org/), and have it
synced even after a device has been offline,
We could send each other rich media like photos,
and could do OMEMO encryption (same as
Signal) in
group chats.
I now have an XMPP setup which has all the features of the recent fancy chat
systems, and on top of that it runs, client and server, on Free Software, which
can be audited, it is federated and I can self-host my own server in my own VPS
if I want to, with packages supported in Debian.
Valhalla has documented the whole procedure.
If you make a client for a protocol with lots of extension, do like
Conversations and implement a status page with the features you'd like to have
on the server, and little green indicators showing which are available: it
is quite a good motivator for getting them all supported.
A few days ago I gave a talk at ESC https://www.endsummercamp.org/ about some reasons why I think that using software and especially libraries from the packages of a community managed distribution is important and much better than alternatives such as pypi, nmp etc. This article is a translation of what I planned to say before forgetting bits of it and luckily adding it back as an answer to a question :)
When I was young, my parents taught me not to accept candy from strangers, unless they were present and approved of it, because there was a small risk of very bad things happening. It was of course a simplistic rule, but it had to be easy enough to follow for somebody who wasn't proficient (yet) in the subtleties of social interactions.
One of the reasons why it worked well was that following it wasn't a big burden: at home candy was plenty and actual offers were rare: I only remember missing one piece of candy because of it, and while it may have been a great one, the ones I could have at home were also good.
Contrary to candy, offers of gratis software from random strangers are quite common: from suspicious looking websites to legit and professional looking ones, to platforms that are explicitly designed to allow developers to publish their own software with little or no checks.
Just like candy, there is also a source of trusted software in the Linux distributions, especially those lead by a community: I mention mostly Debian because it's the one I know best, but the same principles apply to Fedora and, to some measure, to most of the other distributions. Like good parents, distributions can be wrong, and they do leave room for older children (and proficient users) to make their own choices, but still provide a safe default.
Among the unsafe sources there are many different cases and while they do share some of the risks, they have different targets with different issues; for brevity the scope of this article is limited to the ones that mostly concern software developers: language specific package managers and software distribution platforms like PyPi, npm and rubygems etc.
These platforms are extremely convenient both for the writers of libraries, who are enabled to publish their work with minor hassles, and for the people who use such libraries, because they provide an easy way to install and use an huge amount of code. They are of course also an excellent place for distributions to find new libraries to package and distribute, and this I agree is a good thing.
What I however believe is that getting code from such sources and using it without carefully checking it is even more risky than accepting candy from a random stranger on the street in an unfamiliar neighbourhood.
The risk aren't trivial: while you probably won't be taken as an hostage for ransom, your data could be, or your devices and the ones who run your programs could be used in some criminal act causing at least some monetary damage both to yourself and to society at large.
If you're writing code that should be maintained in time there are also other risks even when no malice is involved, because each package on these platform has a different policy with regards to updates, their backwards compatibility and what can be expected in case an old version is found to have security issues.
Contrast this with Debian, where everybody can contribute, but before they are allowed full unsupervised access to the archive they have to establish a relationship with the rest of the community, which includes meeting other developers in real life, at the very least to get their gpg keys signed.
This doesn't prevent malicious people from introducing software, but raises significantly the effort required to do so, and once caught people can usually be much more effectively prevented from repeating it than a simple ban on an online-only account can do.
It is true that not every Debian maintainer actually does a full code review of everything that they allow in the archive, and in some cases it would be unreasonable to expect it, but in most cases they are at least reasonably familiar with the code to do at least bug triage, and most importantly they are in an excellent position to establish a relationship of mutual trust with the upstream authors.
Additionally, package maintainers don't work in isolation: a growing number of packages are being maintained by a team of people, and most importantly there are aspects that involve potentially the whole community, from the fact that new packages that enter the distribution are publicity announced on a mailing list to the various distribution-wide QA efforts.
Going back to the language specific distribution platforms, sometimes even the people who manage the platform themselves can't be fully trusted to do the right thing: I believe everybody in the field remembers the npm fiasco https://lwn.net/Articles/681410/ where a lawyer letter requesting the removal of a package started a series of events that resulted in potentially breaking a huge amount of automated build systems.
Here some of the problems were caused by some technical policies that caused the whole ecosystem to be especially vulnerable, but one big issue was the fact that the managers of the npm platform are a private entity with no oversight from the user community.
Additionally, the long history of the distribution model means that many issues have already been met, the errors have already been done, and there are established technical procedures to deal with them in a better way.
So, shouldn't we use language specific distribution platforms at all? No! As developers we aren't children, we are adults who have the skills to distinguish between safe and unsafe libraries just as well as the average distribution maintainer can do. What I believe we should do is stop treating them as a safe source that can be used blindly and reserve that status to actual trustful sources like Debian, falling back to the language specific platforms only when strictly needed, and in that case:
actually check carefully what we are using, both by reading the code and by analysing the development and community practices of the authors; if possible, share that work by becoming ourselves maintainers of that library in our favourite distribution, to prevent duplication of effort and to give back to the community whose work we get advantage from.
Debian has been moving away from strong ownership of packages by package maintainers and towards encouraging group maintainership, for very good reasons: single maintainers have a bad bus factor and a number of other disadvantages.
When single maintainership is changed into maintainership by a small , open group of people who can easily communicate and sync with each other, everything is just better: there is an easy way to gradually replace people who want to leave, but there is also no duplication of efforts (because communication is easy), there are means to always have somebody available for emergency work and generally package quality can only gain from it.
Unfortunately, having such group of maintainers for every package would require more people than are available and willing to work on it, and while I think it's worth doing efforts to have big and important packages managed that way, it may not be so for the myriad of small ones that make up the long tail of a distribution.
Many of those packages may end up being maintained in a big team such as the language-based ones, which is probably better than remaining with a single maintainer, but can lead to some problems.
My experience with the old OpenEmbedded, back when it was still using monotone instead of git and everybody was maintaining everything, however, leads me to think that this model has a big danger of turning into nobody maintains anything, because when something needs to be done everybody is thinking that somebody else will do it.
As a way to prevent that, I have been thinking in the general direction of a Cat Model of Package Ownership, which may or may not be a way to prevent some risks of both personal maintainership and big teams.
The basic idea is that the my in my packages is not the my in my toys , but the my in my Cat, to whom I am a servant .
As in the case of a cat, if my package needs a visit to the vet, it's my duty to do so. Other people may point me to the need of such a visit, e.g. by telling me that they have seen the cat leaving unhealty stools, that there is a bug in the package, or even that upstream released a new version a week ago, did you notice?, but the actual putting the package in a cat carrier and bringing it to the vet falls on me.
Whether you're allowed to play with or pet the cat is her decision, not mine, and giving her food or doing changes to the package is usually fine, but please ask first: a few cats have medical issues that require a special diet.
And like cats, sometimes the cat may decide that I'm not doing a good enough job of serving her, and move away to another maintainer; just remember that there is a difference between a lost cat who wants to go back to her old home and a cat that is looking for a new one. When in doubt, packages usually wear a collar with contact informations, trying to ping those is probably a good idea.
how small is small depends a lot on the size of the package, the amount of work it requires, how easy it is to parallelize it and how good are the people involved at communicating, so it would be quite hard to put a precise number here.
I've moved away from it because the boards I was using could run plain Debian, but I've heard that after the move to git there have been a number of workflow changes (of which I've seen the start) and everything now works much better.
Virtualization is something that I use, and I have a number of VMs on that laptop, managed with libvirt; since it has microcode version 1067a, I decided to try and see if I was being lucky and virtualization was working anyway.
The result is that the machines no longer start: the kernel loads, and then it crashes and reboots. I don't remember why, however, I tried to start a debian installer CD (iso) I had around, and that one worked.
So, I decided to investigate a bit more: apparently a new installation done from that iso (debian-8.3.0-amd64-i386-netinst.iso) boots and works with no problem, while my (older, I suspect) installations don't. I tried to boot one of the older VMs with that image in recovery mode, tried to chroot in the original root and got failed to run command '/bin/bash': Exec format error.
Since that shell was lacking even the file command, I tried then to start a live image, and choose the lightweight debian-live-8.0.0-amd64-standard.iso: that one didn't start in the same way as the existing images.
Another try with debian-live-8.5.0-i386-lxde-desktop.iso confirmed that apparently Debian > 8.3 works, Debian 8.0 doesn't (I don't have ISOs for versions 8.1 and 8.2 to bisect properly the issue).
My next attempt (thanks tosky on #debian-it for suggesting this obvious solution that I was missing :) ) was to run one of the VMs with plain qemu instead of kvm and bring it up-to-date: the upgrade was successful and included the packages in this screenshot, but on reboot it's still not working as before.
Right now, I think I will just recreate from scratch the images I need, but when I'll have time I'd like to investigate the issue a bit more, so hopefully there will be a part 2 to this article.
With http://debconf16.debconf.org/ being in South Africa, a lot of people (like me) probably weren't able to attend and are missing the cheese and wine party, mao games and general socialization that is happening there.
What they do, however, requires a lot of manpower, so if you are attending Debconf please consider volunteering https://wiki.debconf.org/wiki/Videoteam/roles_for_volunteers to help: from my experience last year they are very nice people who are welcoming towards new contributors and they have periodical training sessions to help people getting started with the various tasks. More informations about video team meetings and training session are in the topic of the IRC channel, #debconf-video@OFTC.
I don't think there are cookies involved (which just proves that the video team isn't evil), but you may get a t-shirt and you will get a warm fuzzy feeling of having helped people around the world.
About one year ago, during my first http://debconf15.debconf.org/, I've felt the need for some way to tell people whether I was busy on my laptop doing stuff that required concentration or just passing some time between talks etc. and available for interruptions, socialization or context switches.
One easily available method of course would have been to ping me on IRC (and then probably go on chatting on it while being in the same room, of course :) ), but I wanted to try something that allowed for less planning and worked even in places with less connectivity.
My first idea was a base laptop sticker with two statuses and then a removable one used to cover the wrong status and point to the correct one, and I still think it would be nice, but having it printed is probably going to be somewhat expensive, so I shelved the project for the time being.
Lately, however, I've been playing with hexagonal stickers https://terinjokes.github.io/StickerConstructorSpec/ and decided to design something on this topic, whith the result in the figure above, with the hacking sticker being my first choice, and the concentrating alternative probably useful while surrounded by people who may misunderstand the term hacking .
While idly looking around for sticker printing prices I realized that it didn't necessarly have to be a sticker and started to consider alternatives.
One format I'm trying is inspired by "do not disturb" door signs: I've used some laminating pouches I already had around which are slightly bigger than credit-card format (but credit-card size would also work of course ) and cut a notch so that they can be attached to the open lid of a laptop.
They seem to fit well on my laptop lid, and apart from a bad tendency to attract every bit of lint in a radius of a few meters the form factor looks good. I'll try to use them at the next conference to see if they actually work for their intended purpose.
Tonight I've dreamt I was inside https://wl.widelands.org/, as a barbarian being invaded by the atlanteans.
I've had the same thing happening to me a few times with Battle for Wesnoth http://wesnoth.org/
Mayyybe it is a sign that lately I've been playing it too much, but I'm quite happy with the fact that free software / culture is influencing my dreams.
Thanks to everybody who is involved into Free Culture for creating enough content so that this can happen.
The 
Some days ago, me and 
Valhalla eventually managed to get all features activated, purely using
packages from Jessie+Backports:
The result was a chat system in which I could see the same conversation history
on my phone and on my laptop (with gajim)(https://gajim.org/), and have it
